Jason Knight 0:00 Hello, and welcome to the show. I'm your host, Jason Knight. And on each episode of this podcast, I'll be having inspiring conversations with passionate people in and around the wonderful world of Product Management. If that sounds like the sort of thing you can get behind, why not come and join me and some of the finest thought leaders and practitioners in the world on https://www.oneknightinproduct.com, where you can sign up to the newsletter, subscribe on your favourite podcast app or follow the podcast on social media, and guarantee you never miss another episode again. On tonight's episode, we talk about API's No, no, no, don't go. We're talking about API products. What is an API? What is an API product? How do we measure success in our API products? And what does an API vanity metric look like? And all in all, an API products totally different to other products? Or is the fundamental job just basically the same? answers to all these questions, and much more, please join us on One Knight in Product. Jason Knight 0:49 So my guest tonight is Deepa Goyal. Deepa's a former data scientist and data product manager turned API product manager in these days, she's our product strategist. And now an author who wants us all to know, if we build on our strengths, we can be very successful. She obviously hasn't heard about all my weaknesses. Deepa's a trained artist who loves to paint large scale portraits, and apparently got some early practice in saying no to CEOs. When she was asked to get a matching tattoo done. She's now taken all the ink she saved and created her own work of art. The recently released API analytics for product managers, and she wants you to understand the key API metrics that can help you grow your business. Hi, Deepa, how are you tonight? Deepa Goyal 1:36 Hi, Jason. Thanks for having me. Very excited to be here. And thanks for the great intro. Jason Knight 1:40 Absolutely. It's good to have you here. And just get started in my time out of fashion, you are currently the product strategy lead for Postman. Probably most people out there will have heard of Postman, the go to solution for testing your own API's. But in any case, what are you working on day to day at Postman? Deepa Goyal 1:59 So as you already mentioned, it is the go to tool for API testing. And I think we want to really go beyond testing. And what I'm working on day to day is how can we unlock getting more and more people who are not necessarily so technical? How can we enable them with tools to work with API's? How can we enable people to build different kinds of API's, what kind of tooling they will require to build public API's or internal API's and managing API's at scale? One of my key areas of focus is actually enterprise. And just how enterprises build their API's they have a lot of them have 1000s of API's, how does that management look like? And what makes sense in terms of tooling? When you have 1000s of developers working in an organisation? Jason Knight 2:55 Yeah, well, you know, that's obviously always gonna be a challenge for any type of product, you know, the more people you're setting into the more users but it sounds like a really interesting challenge, this idea that you're trying to almost open up that near mythical world of API's, the sort of thing that not everyone really gets in trying to open it up to the world as well. And we're gonna talk about that a little bit in a minute, as well, kind of like some of the concepts around API's. But I guess one of the questions I do have about being a kind of Product Strategy lead, as opposed to say, you know, just in quotes, a product manager, or a head of product, or some kind of VP of product, that you very specifically got strategy in your job title. Yep. So how does that then differ from? Or how does your role then differ from some of those more traditional kind of job title roles? Like, are you kind of up there on your ivory tower? Just thinking about stuff all day? Or do you kind of still have to go and get your hands dirty, either in JIRA, or maybe even in Postman itself from time to time? Deepa Goyal 3:50 It is, I don't really spend that much time in my ivory tower, I do get my hands dirty. And I think that the way my role is different from the traditional product manager roles that I've held before, is instead of focusing on sort of shipping features, I'm also more broader in terms of I work with different product managers across the organisation. And tied together across the organisation. I am also a little bit more exposed to our external customers or stakeholders. And I also work very closely with our go to market teams, and trying to stitch that big picture, but I don't manage people directly. I think that's really the difference between traditional Head of Product role and and my role. I'm not really managing people directly. It's a little bit more of thought leadership within the product. Org since we do have a different org structure. Jason Knight 4:50 Oh, absolutely. Well, it sounds like you've got a good mix of different things there. And you know, not everyone wants to manage people. So hopefully that's something that kind of jives with your preferences, but You've worked in API products for a lot of your career, or certainly the last few years of your career. So you're working at postman now. You spent a bit of time as the head of API experience at PayPal. You've worked at Twilio. So you've worked for some pretty big companies. You've worked on API's for some pretty big companies. I'm sure you've said a few things. But what was it that got you into or attracted you to working with API products in the first place? Was it like a really intentional move, or just kind of happenstance Right place, right time? Deepa Goyal 5:29 Definitely intentional. I was at Prosper marketplace. And I helped build some of their API's... partner API's. And that time, I didn't know that much about API as a product and what other companies are doing. And I went to a few conferences with devs on my team and learned about all these cool API's. And I was fascinated by it. And I decided, I started looking into Twilio, because I saw somebody show a project. So that's really how the Twilio move came about very much out of my interest in API's and all the incredible things people were doing with API's. And once I got in, I was very interested in this idea of API as a product. And I found it really fascinating. I was interested in it, but there seems to be no information out there to help people get more aware about it. So that's really how I started in API, product management is out of sheer interest and learning on the job. And all the moves from Twilio, to PayPal, and now postman have really helped me look at different dimensions of API as a product. And it's been great. Jason Knight 6:55 Yeah, that's really interesting. And you know, I've worked on API products before as well. So I've got maybe not so much experience as you have, but certainly sort of been around the block a bit. But I guess one interesting question is, when you've been going for potentially new roles, for example, obviously, as an API specialist, now, I guess you could call you like, Are there lots of API product manager jobs out there? Or is it kind of a case of trying to find the ones as they come up? And, and really go for those? Like, I don't know, like what the landscape is. But is it something that it's quite easy to get into? Or do you think that it's a little bit more tricky? Deepa Goyal 7:31 So there's two questions. They're questions you asked there. One is, how many jobs are there? I think the the number of jobs in the API space have consistently been increasing. Since more and more companies are looking to build API's and spending more energy and focus on their API experiences as they try to roll out API products. I would say it's not as honestly, it's not very easy to get it. I would not sugarcoat it. I think there is a barrier to entry in terms of being slightly technical, since working with API's can be technical, there is that there is the aspect of like, there is not enough guidance out there in terms of how do you do this job and what is expected or how these companies operate. And those two things combined, definitely make it harder for new PMS, to enter this space. But there is huge demand. I think there is a lot of a lot of opportunity for people who are looking to get into it. Jason Knight 8:31 Well, let's talk about some of that guidance. And so you've got your new ish book out API analytics for product managers, been very kind and sent me a copy. So obviously, as a former API product person, myself had a good read through that. And it's nice to see some very familiar concepts. And obviously some new takes on some stuff as well. But I'm always keen to see API's given a little love and start to treat them as the first last product citizens that they are. But what made you want to write a book about this stuff in the first place? I mean, you've talked about the lack of resources for it. I mean, I assume that was part of it. But what specifically inspired you to be the person to write this book? Deepa Goyal 9:08 So of course, as I looked through the books, there was a lot of engineering related content, a lot of books telling you, from an engineering perspective, how to build API's, but there wasn't enough strategy aspect being discussed, not enough customer empathy being discussed. And that was one of the challenges that I started with at Twilio, where I actually got the opportunity to talk to a lot of customers do a lot of this work myself. And as I started doing that, I started creating the strategy for analytics for this kind of product. I had done analytics for different kinds of products before. So I started to create a framework for approaching this set of problems. And I think as I created that framework, I was like Okay, you know what, this is not just useful for my current job, but this is something that everybody can benefit from. And honestly, I feel like if this knowledge exists, why does everybody have to reinvent the wheel? And if if I share this people who are trying to establish metrics or you know, get into product management for API's, maybe they can get started much quicker, and get to success much faster. So that was really my motivation. Jason Knight 10:33 Oh, absolutely. But then was that something that almost wrote itself, then or did it take quite a lot of effort to try and take some of those frameworks and approaches that you'd maybe already been thinking about, or using and actually convert those into a book that was actually consumable by the wide world of product managers out there, Deepa Goyal 10:49 it was a lot of work. I think, also, my ideas got refined a lot on the way, I had access to a lot of experts in the space like Kin Lane, and Arno Lauret, who has also written books on the topic. So having those experts kind of easy access to them really allowed me to bounce off ideas and, and get that perspective in terms of like, Hey, this is how I'm thinking about it. And then being able to poke holes in it really helped me to find some of those ideas, and also validate some of the things that I I was thinking about. So if this, is this really a problem, and they're like, oh, yeah, this is really a problem. So I think it's really helps to have that people, you know, asking people and validating that this is really something worth writing about something people are looking for. And in terms of writing itself, I'm not a natural writer, it was a huge effort to push myself to write, it took a while to establish a writing style for myself, I think it's easy to think of like, Oh, I'm going to write a book about it. But the actual writing of the book is very difficult, takes a lot of perseverance. And there are many moments where you wonder if you will be able to finish it. In my case, after I started the book, I found out that I was expecting a baby. And I wrote the book through it. So it was it was a while but I but but honestly, I was just I, I had a timeline in mind, I had to get the book out this year. And I was just determined to get it done. Jason Knight 12:35 Well, and you made it. And it's interesting though, that thing you say around assessing whether this was a real problem, and whether that's something that would have an audience. And this is all exactly the same struggle that product managers API, or otherwise have with all of their products as well. So almost taking some of those product principles, and then bringing them back and focus in on your own book as well, which is definitely interesting. But some people might read the title and think, Well, you know, API analytics sounds pretty exciting. But I don't know anything about API products at all yet. So do I need another book for that? So I guess the question for you would be, does the book kind of take people from zero to one? So someone who's never managed an API product at all in their lives? And there may be interested in getting into the space and they need something to guide them along the way? Or is it something that's really optimised for people that already are API product managers, and just need to get better at being one of those? Deepa Goyal 13:28 My book definitely is, takes people from zero to one. My book starts with just sharing about what API's are. And what API is a product even means. So I really wanted to get people started in terms of, if you know, absolutely nothing about API's, and you don't even know who's doing it in the industry, you get a good feel of the API landscape, what kind of products already exist and how they approach the same problems. And then dig deeper into how you can do user research, identify your customers, build customer empathy, and also have the right Analytics to measure along the way and form a more complete and coherent API strategy. Jason Knight 14:21 Oh, there you go. So hopefully, people can pick it up and start along that journey. But let's talk a bit more. I mean, you just touched on it yourself about the kind of almost a fundamental questions of API product management, you know, what is an API? And what can you do with it and all of those things, so let's kind of take it from the top just in case there are people listening to this that maybe know a little bit about API's, but they don't really know what's going on. And maybe they need to go a bit on that journey, too. So obviously, API's can be a fairly tricky technical concept hard to explain to non technical people. So I'm going to ask you to explain it. Maybe not to a six month old because you know, I know ... kids over there. But you know, he can't he can't understand it properly yet. But like if you had to explain API's to say a seven year old, maybe to my son, how would you describe an API to that boy? Deepa Goyal 15:12 That's really interesting. I think API is a natural thing. The simplest definition of API's in my mind is API's are how applications can be programmed to talk to each other. And a very simple example of that is when, when you open the Uber app, for example, you you see this map, where you can see your location. And when you call for an Uber driver, you can see his or her location. And this is Uber calling Google Maps API's to render this information. So in the background, Google and Uber are talking to each other to get you this information. Or when you accept when you decide to pay by PayPal, on any app, let's let's say for example, Uber, and you say, I want to pay with PayPal, that's Uber talking to PayPal, API's in the background, PayPal API saying yes, this is deeper, you can this is validated account. And yes, you can take the payment. So at scale, all these services and applications are able to talk to each other using API's. And for the end user, it's this seamless experience that allows this world class experience of like Google is the best mapping PayPal, you already have PayPal, so you don't have to configure a new payment method or credit card. So this ease of your user experience is delivered by all these applications talking to each other. And that's enabled by API's. Jason Knight 16:50 Oh, there you go. I'm gonna play a recording of this to that boy after this, just to see if he understands all of that. But obviously, a fairly user centric approach there, which is obviously maybe segues nicely into the next question, which is like, if we accept what an API is. And if we accept that lots of products have API's kind of underneath them, maybe like internal API's that are used for themselves to kind of just make the web app that you log in to just talk to itself? We're not talking about that type of API, we're talking about API's where things can talk to each other, like different products can talk to each other. So if you were to describe an API product, specifically, how would you do that, and this can be pitched at grownups, it doesn't have to be to seven year olds. Deepa Goyal 17:35 So API products don't necessarily have to be external API's. I think it's really about what what we're coming up with, as an industry is thinking about API's in general, as products, because even when you build internal API's, the internal developers are your customers. And the problems actually remain the same. If you have 1000s of API's within an organisation, you still want the developers to be able to discover them to be able to integrate effectively with them. You want to avoid everybody trying to build the same API's and avoid that. Classic. Exactly, exactly. So it's the approach of trying to think about API's as products and building a customer centric approach and strategy, be it internal, or external, or even if it's like, built for specific customers, which is partner API's. So applying that customer centric approach to building API's. Jason Knight 18:38 So just to clarify that, if you're talking about internal API's, I mean, it's starting to make me think of some of the concepts of Team topologies. And books like that, where you've kind of got your enabling teams and your platform teams and all your different types of teams. So you're very much advocating to have a, an internal API product manager for an internal API rather than just two engineering teams talking to each other. Deepa Goyal 18:59 Absolutely. I think product managers are needed even for building internal tools or internal API's. Ultimately, internal developers are also customers to their API's. And if you have a good experience, internally, it can actually benefit the overall engineering organisation in terms of efficiency, in terms of security, as well. Because if different teams are building the same API's, how do you really measure which one's better or you have this redundancy, this inefficiency in your organisation so I think efficiency gain is a huge, huge item for anybody building internal API's, especially as we get to scale of large organisations building 1000s of API's, Jason Knight 19:50 but day to day them, what are some of the main differences you see between managing some random web products, you know, sort of product that lots of people listed? interdisciplinarity managing things that people can just log into on their browsers and get going. And it's all very kind of glitzy and you know, nice to look at and stuff like, what are some of the differences between product managing that type of product and product managing an API product, Deepa Goyal 20:14 there's quite a few differences. I think, from the web perspective, you have the opportunity to track clicks, as your user goes through their user journey of using your product, which is not necessarily something you have with an API product, especially in the early stage of, you know, people onboarding with your API's. So that onboarding journey of the customer tends to be much less trackable than a web product. And also much longer in terms of time. Because when, when a developer discovers an API and tries to integrate, that could be a few days that could be a few weeks could be sometimes in case of larger organisations, could be months, before they actually come online and start using your API's. Jason Knight 21:07 Yeah, I mean, we'll talk maybe a little bit more about that time to value piece in a moment, because that's something that's obviously in fact, let's talk about it now. Like, you just kind of hit the nail on the head. And it's definitely something that I've seen myself in the past, like you've got an API of whatever quality that API is, but you've got something that you can take out to the market, people can buy, they can subscribe to all that stuff. But you, you really touched on a really important point, like, we're so reliant on other people, to allow them to get value from our API's, we can't give them value until they've integrated. So what are some ways that we can make it easier like so if we've got an API product, and we do sell it to someone to make it as easy as possible to get those people up and running as quickly and as seamlessly as possible? Deepa Goyal 21:56 I think that's where analytics comes into play, you have to... Jason Knight 21:59 Oh well what a coincidence! Deepa Goyal 22:01 So there's two different things, two very important metrics that that I think about what is time to first call? Yep, that is just trying to track that somebody was able to get started with your API's, they could sign up, create an account, get their keys and make an API call. And I think that is just the getting started. But when we think of time to value, that is more to do, that can vary with with the nature of the business. So for example, for PayPal, the time to value is when you make an actual financial transaction, and money is moved and you make a payment. And that could potentially take more than a single API call. validating your account, and you know, all those different things as you go through that journey. So you can identify that business transaction as value. Because if I'm a merchant, and I integrated PayPal API's, I can do it for fun, but the value is when people actually start paying me using PayPal. So that is really the business idea of value. So time to value can be defined differently for different products. And it can be very different from time to first call. And the way you can think about optimising the experience is to reduce that distance, if ultimately, it shouldn't take too long after your first API call to get to value. Jason Knight 23:37 But I want to maybe dive a little deeper than into that concept of value. Because so for example, in the past, I've worked on data API's. So like API is the exposed data that basically other companies call with every single transaction that they do, or every new customer that they bring on board at their site. So obviously, the usage of the API is very much dependent on how many customers they onboard, because that's the part of the flow that it's in for them. They're kind of integrated in, I can't make the music more because it's just wired up to every single transaction that they do. And obviously, in the case of something like PayPal, we could argue, sure, money, you know, that's the ultimate value, right? But is there an easy way to kind of carve out either an actual metric or a proxy metric? Or some kind of way to tell that it's not just that I'm plugged in, but that I am actually, over time delivering value and potentially being able to deliver more value? Or is it always kind of imperfect when you're dealing with a fairly wired in API that they're kind of just using every time they make a transaction anyway? Deepa Goyal 24:43 So that's a very good question. So the definition of value can vary a lot. And what I've seen is one of the ways that I've kind of approached this problem and I've observed is value can mean different things to different customers. Yes, So for example, when I was at Twilio, some of our customers were small nonprofits, and some were large enterprises. And success to a small nonprofits could be 50 SMS, a week, which is very low. So from Twilio perspective, it's not necessarily driving a lot of revenue at 50 calls a week, but it is still delivering value to this customer. Yep. And that could be millions of calls for large customers. And what I've seen over time is trying to track that recurring usage is very helpful in terms of identifying value. Once you start to observe that a customer is repeatedly using your API, you can assume that they have integrated successfully, they are starting to depend on it. And also that weekly usage will grow as they grow. And oftentimes, it could be impacted by the industry as a whole. But that recurring usage is a very good signal of value to the customer. Jason Knight 26:09 Yep, that's fair enough. But one thing that I've seen often when trying to demo API products, so if we kind of go back to this concept of demonstrating value, of course, they're not going to get any value out of it unless they buy it. And in many cases, they're not going to buy it unless it's some fully product led growth, you know, sign up on the website and just integrate with a help page, a lot of API products, or maybe still Sales Lead being sold in as part of a bigger enterprise deal or something like that. And it can be quite tricky to demonstrate that value of an API to a roomful of basically commercial stakeholders or like operations, people that basically wouldn't know one screen of JSON data to another screen of JSON data. Now, obviously, a tool like postman allows you to very easily query API's, but like, I'm going to assume that like the head of operations of a midsize to large size enterprise isn't necessarily going to be the that's not gonna be their first port of call, right. So are there any ways that you've seen or ways that you recommend to try to demonstrate the value of the API's that you're putting out there to kind of business stakeholders that don't really understand any of the technicalities, but they just want to see what it does? Deepa Goyal 27:20 Yeah, absolutely. So what are the what are the ways that I've seen work in terms of demonstrating API value is, by having some demo instances, usually companies would create examples that are domain specific. So you have something to look at in terms of what you can build using these API's. So it's a dummy application that you can build, and demonstrate the features and functionalities of your API's just to show the possibilities to your customers, API's do tend to be very sales lead. So there's definitely that aspect of your sales team is going to be a key driver of your strategy. And they would be part of your communication channel to the customers. And oftentimes, they are the ones doing the demonstrations. And in my experience, salespeople have been incredibly amazing at taking something very technical, and be able to share it with different kinds of stakeholders. I think it's a it's a great talent that sales teams possess. Jason Knight 28:29 But it's interesting, though, because I guess some people might sit there and think, Well, you know, API is very technical products, primarily, I guess, the end user being developers or integration teams within other companies. And, you know, maybe all of the kind of almost all of the sales enablement and stuff would all be super focused on the developers and super focused on the kind of technical capabilities of the API. But feels like you're really talking about making sure that those sellers that those salespeople are out there with good sales enablement, that actually talks about the the kind of the vision and what it enables and all the cool things that you can do, and maybe not getting too much into the technical details at that stage at all. Is that fair? Deepa Goyal 29:11 Not necessarily. I think there is this aspect of when we think of developers, we oftentimes think of the engineer or the programmer. But when we build API's, we have to think of developer as a little bit more broader persona. And it's not always a coder. It's not always a large team of developers and an enterprise. It really varies. And low code. No code developer, is as much a developer as anybody else. And when we think about building our API's as product, we have to think about how to enable these customers who may not be as technical so providing them the tools to be able to onboard using your API's without having to code as much giving them that's a copy paste code. or some kind of code generation to or building up an experience that has a click through integration is very key in trying to broaden your customers from just programmers to actually really all kinds of customers. Jason Knight 30:16 You gotta win the battle for hearts and minds. But as PMs, we're often warned against vanity metrics. You know, you talked a little bit before about some of the metrics that maybe you do want to track to understand that you're delivering value and that your that your users are getting the best out of the API's that you're selling to them. But are there any API vanity metrics out there that sound like they're really good things to measure, but actually, don't really stand up to scrutiny? If I mean, you talked a little bit about, for example, particular endpoint calls not necessarily being a big predictor, because maybe there's lots of calls that represent value. But are there any other kind of big no no's when it comes to API analytics, where you sit down and say, yeah, just don't measure that? Or that doesn't mean what you think it does? Deepa Goyal 31:00 I think time to first call is definitely one of those, which is widely recommended as, like the ultimate metric. But it's not entirely a vanity metric. But it is definitely not, not a complete metric. Jason Knight 31:19 I was just thinking like, well, that type of second call, like anyone can make a first call, right? Deepa Goyal 31:24 Exactly. So one of the things we do is, one of the ways you can identify it will go forward from first call is have depending on your scale, let's say you identify 100, as the number of API calls, which is significant telling of your customer journey, then you can say that time 200 Call is really your activation. So a lot of times the time to first call is just tends to be a little bit of a vanity metric, you have all these developers experimenting, making a call and dropping off. Jason Knight 31:58 Absolutely. But we've talked a lot about some of the differences and some of the different considerations that you might have as an API product manager. But I want to also inspire maybe people that are considering this and maybe don't know where to start, maybe they'll read your book, maybe they'll go and do some other things. But I want to kind of reassure them that there are some things about API product management that are the same. So we've talked about the differences. But what's the same for an API product manager at the heart of it? Like is it the same job, but just a slightly different product? Deepa Goyal 32:29 Absolutely, I think the fundamentals of Product Management remain the same, you still care about the customer, you still try to make an impact and drive business results. I think the nature of the product changes, what stakeholders you have, and what metrics you measure. And just how you go about doing things, you still do user research, how you do user research might be different in terms of how you do it for a web based product for an e-commerce business versus an API product. But you still have the same steps and the same thought process. Jason Knight 33:06 Oh, there you go. Hopefully, that will inspire a few people to try and find out a little bit more. But if they do want to go and find out a little bit more, and get in touch with you to either find out some extra information about the book or talk about API product management in general, or see if they can persuade you to get a lovely product management tattoo work? Deepa Goyal 33:24 So people can find me on Twitter. My handle is @1sprintatatime because the greatest products out there are built one sprint at a time. Jason Knight 33:33 Oh, come on, we don't want to get tied into Scrum do we?. Deepa Goyal 33:38 You can also find me on LinkedIn, Deepa Goyal. And I'm always happy to answer questions. You can find my book on Amazon. It's called API Analytics for Product Managers. Jason Knight 33:50 Well, I'll make sure to link that all into the show notes. And hopefully you have a few people heading your direction and making that first call to see where they can go. Well, that's been a fantastic chat. So obviously, really appreciate you spending some time geeking out on API products with me. Obviously, we'll stay in touch. But yes, for now. Thanks for taking the time. Deepa Goyal 34:07 Thank you so much. This was really fun. And I hope we are able to inspire a few people to get into API product management. There is a lot of opportunity and demand. So I'm really excited for all the people who are looking into it. Jason Knight 34:22 As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to hop over to https://www.oneknightinproduct.com check out some of my other fantastic guests sign up to the misters Skype on your favourite podcast app and make sure you share your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest but as for now, thanks and good night.